Windows NT has always had a rich access control model
to protect sensitive system resources from modification by or
disclosure to unauthorized entities. Within this model, user accounts
are typically given Administrator rights or User rights. Administrators
have complete and unrestricted
access to the computer and all its resources, while Users are
restricted from making changes to operating system configuration or
accessing data belonging to other users. For historical reasons,
however, until recently end users on Windows computers were frequently
granted administrative access, so many people have remained unaware that
these distinctions exist. (Even today, the first local user account
created on a Windows 7 computer is a member of the Administrators
group.)
Note:
Users can have effective
administrative control over a computer without explicit membership in
the Administrators group if they are given the ability to configure or
control software that runs in a more powerful security context—for
example: granting users control over systemwide file or registry
locations used by administrators or services (as Power Users had before
Windows Vista); granting users “admin-equivalent” privileges such as the
Debug, Take-Ownership, Restore, or Load Driver privileges; or enabling
the AlwaysInstallElevated Windows Installer policy, under which any MSI
file launched by any user runs under the System account.
Recently, organizations
wishing to improve security and reduce costs have begun moving toward a
“non-admin” model for their end users. And with Windows Vista’s
introduction of User Account Control (UAC), most programs run by
users—including those who are members of the Administrators
group—execute with user rights, not administrative rights. However, it
sometimes becomes necessary to run a program with administrative rights.
While many people didn’t know how to do this in Windows XP, Windows
Vista changed those methods significantly.
Many of the
Sysinternals utilities always require administrative rights, while many
have full functionality without them. Some, however, are able to work
correctly with standard user rights but have features that need
administrative rights, and thus operate in a “partially degraded” mode
when executed with standard user rights.
1. Running a Program with Administrative Rights on Windows XP and Windows Server 2003
If you log on to a Windows XP or
Windows Server 2003 computer with an account that is a member of the
Administrators group, no special steps are required to run a
Sysinternals utility with administrative rights. Every program you run has full administrative rights.
But if you log on to that
same computer with an account that does not have the required
privileges to run a particular Sysinternals utility, you will need to
get the administrative rights from a different user account. The
Secondary Logon (Seclogon) service enables programs to start a new
process as a different user on the current desktop by supplying
alternative credentials. Two programs that expose this functionality are
Explorer’s Run As dialog box and the Runas.exe command-line utility.
To
use the Run As dialog box to start a program with administrative
rights, right-click on any program or shortcut in Explorer or the Start
menu and choose Run As from the context menu. In the Run As dialog box,
choose the second radio button (“The Following User) as shown in Figure 1,
type the credentials for an administrative account, and click OK. You
can make Run As the default for a shortcut by opening its Properties
dialog box, clicking the Advanced button, and selecting the “Run With
Different Credentials check box.
To start a program
with administrative rights with the Runas.exe command-line utility, open
a command prompt and start Runas.exe with this syntax:
runas /u:username program
For example, to run Process Monitor (Procmon.exe) with the local Administrator account, run the following command:
runas /u:administrator procmon.exe
After you press Enter,
Runas.exe prompts you for the account’s password. You must type the
password at the prompt; Runas.exe does not accept a password on the
command line nor piped to it from the standard input stream. You can use
the /savecred command-line option to save the account’s password the first time you enter it; subsequent use of /savecred
with the same account will retrieve the saved password so that you
don’t have to enter it again. While this behavior is convenient, note
that the standard user under whose account the administrator’s password
is saved can now use Runas.exe to launch any program without having to supply the password.
To use smartcard authentication instead of password authentication, add the /smartcard option to the command line. You will be prompted for a smartcard PIN instead of a password.
For
more information and tips about using RunAs, see Aaron Margosis’ “RunAs
basic (and intermediate) topics” blog post at the following URL:
http://blogs.msdn.com/b/aaron_margosis/archive/2004/06/23/163229.aspx
If you need the
Sysinternals utility to run with full administrative rights but under
your nonadministrator account (for example, so that it can authenticate
to domain resources), you can use Aaron Margosis’ MakeMeAdmin script. It
invokes Runas.exe twice to launch a command prompt that runs under your
current account but with full administrative rights. (Note that you
must have credentials for an administrative account to make this work.)
For more information, see his “MakeMeAdmin — temporary admin for your
Limited User account” blog post at the following URL:
http://blogs.msdn.com/b/aaron_margosis/archive/2004/07/24/193721.aspx
2. Running a Program with Administrative Rights on Windows Vista or Newer
Windows Vista and
UAC changed everything when it came to running programs with
administrative rights. Running as a standard user is now the default
state for users’ programs, even when run by a member of the
Administrators group.
If you log on to a computer
running Windows Vista or newer with an account that is a member of
Administrators (the first account is the only one that defaults to
Administrators group membership on computers not joined to a domain) or
another powerful group such as Backup Operators or that has been granted
“admin-equivalent” privileges, the Local Security Authority (LSA)
creates two logon sessions for the user, with a distinct access token
for each. One of these tokens represents the user’s full rights, with all groups and privileges intact. The other is a filtered
token that is roughly equivalent to one belonging to a standard user,
with powerful groups disabled and powerful privileges removed. This
filtered token is used to create the user’s initial processes, such as
Userinit.exe and Explorer.exe, and is inherited by their child
processes. Starting a process with the user’s full token requires UAC
elevation, mediated by the Application Information (Appinfo) service.
The Runas.exe command is still present, but it does not invoke the
Appinfo service—so its effect is not quite the same as it was on Windows
XP. If you start a program with Runas.exe and specify an administrative
account, the target program runs under the “standard user” version of
that account.
UAC elevation can be triggered for a new process in one of several ways:
The program file
contains a manifest that indicates that it requires elevation.
Sysinternals GUI utilities such as Disk2Vhd and RAMMap that always
require elevation contain such manifests.
The
user explicitly requests that the program run elevated—for example, by
right-clicking it and choosing Run As Administrator from the context
menu.
Windows
heuristically determines that the application is a legacy installation
program. (Installer detection is enabled by default, but it can be
turned off through a security policy.)
The application is associated with a compatibility mode or shim that requires elevation.
If the parent process is
already running with an administrative token, the child process simply
inherits that token and the UAC elevation sequence is not needed. By
convention, console utilities that require administrative rights (for
example, Sysinternals LogonSessions) do not request UAC elevation.
Instead, you should start them from an elevated command prompt or
Windows PowerShell console.
Once triggered, UAC elevation can be accomplished in three ways:
Silently
The elevation occurs without end-user interaction. This option is
available only if the user is a member of the Administrators group. By
default in Windows 7, silent elevation is enabled for certain Windows
commands. Silent elevation can be enabled for all elevation requests
through security policy.
Prompt For Consent The user is prompted whether to permit the elevation to occur with a Yes/No dialog box. (See Figure 2.)
This option is available only if the user is a member of the
Administrators group and is the default (for elevations other than the
default silent elevations of Windows 7).
Prompt For Credentials The user is prompted to provide credentials for an administrative account. (See Figure 3.)
This is the default for nonadministrative accounts and is the only way
that UAC elevation can be achieved by a nonadministrative user. You can
also configure this option for administrative users with a security
policy setting.
Note that UAC elevations can
be disabled for standard users via security policy. When the policy is
configured, users get an error message whenever an elevation is
requested.
When
User Account Control is disabled, Windows reverts to a mode similar to
that of Windows XP. In that case, the LSA does not create filtered
tokens, and programs run by members of the Administrators group always
run with administrative rights. Further, elevation prompts do not
display, but Runas.exe can be used to start a program with
administrative rights. Note that disabling UAC also disables Internet
Explorer’s Protected Mode, so Internet Explorer runs with the full
rights of the logged-on user. Disabling UAC also turns off its file and
registry virtualization, a feature that enables many applications that
required administrative rights on Windows XP to work with standard user
rights.
